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Epistemology, Software Engineering, and Formal Methods 


Abstract of Presentation 
C. Michael Holloway 


One of the most basic questions anyone can ask is, 
"How do I know that what I think I know is true?" The 
study of this question is called epistemology. Tradi- 
tionally, epistemology has been considered to be of 
legitimate interest only to philosophers^ theologians, 
and three-year-old-children, who respond to every 
statement by asking, "Why?" Software engineers need 
to be interested in the subject, however, because a lack 
of sufficient understanding of epistemology contributes 
to many of the current problems in the field. 

Epistemology is a complex subject, one to which 
many philosophers and theologians have devoted their 
entire careers. The discussion here is necessarily brief 
and incomplete; however, it should be sufficient to 
demonstrate the critical importance of the subject to 
software engineering. 

To the fundamental question of how do we know 
what is true, there are three basic answers: authority, 
reason, and experience. An epistemology based on 
authority states that truth is given to us by someone 
more knowledgeable than ourselves. The two primary 
variations of authority-based epistemologies are omni- 
scient authority (the authority is God), and human 
authority (the authority is a human expert). 

An epistemology based on reason claims that what 
is true is that which can be proven using the rules of 
deductive logic. Finally, an epistemology based on 
experience claims that what is true is that which can be 
encountered through one or more of the senses. 

Several different variations of experience-based 
epistemologies exist. The two variations relevant to 
this discussion are anecdotal experience and empirical 
evidence. The first states that truth for any particular 
individual or group of individuals is that which the 
individual, or group, personally experiences. The sec- 
ond states that truth is that which can be verified 
through carefully controlled experiments. 

The relative strengths of these epistemological 
approaches are as follows. Omniscient authority pro- 
vides absolute truth; if there is a God and He has spo- 
ken on something, then what He says must, by 
definition, be true. Reason yields conditional absolute 
truth; if the premises on which a valid deductive argu- 
ment are known to be true, then the conclusion of tile 
argument must also be true. 

Empirical evidence provides probable truth; if con- 
trolled experiments are designed properly and repeated 
enough times, then it is highly probable that the results 


accurately describe reality. Anecdotal experience 
yields possible truth; if something happened for one 
person, it is possible it might happen to others also. 
Finally, human authority provides opinion. 

On which of these approaches to epistemology is 
software engineering mostly based? 

The software engineering literature is filled with 
pronouncements about how software should be devel- 
oped (e.g.„ “ Object-oriented development is the best 
way to obtain reusable software"). Rarely, if ever, are 
these pronouncements augmented with either logical or 
experimental evidence. Thus, one is forced to conclude 
that much of software engineering is based on a combi- 
nation of anecdotal experience and human authority. 
That is, we know that a particular technique is good 
because John Doe, who is an expert in the field, says 
that it is good (human authority); John Doe knows that 
it is good because it worked for him (anecdotal experi- 
ence). This is a weak epistemological foundation on 
which to base an entire discipline. 

This current state should not be surprising; the 
development of software engineering is following the 
same pattern as the development of many other disci- 
plines. Civil engineering, chemical engineering, aero- 
nautical engineering, and others all had periods in 
which they relied almost exclusively on anecdotal 
experience and the subsequent authority of the 
“experts”. Often, it took major disasters before practi- 
tioners in such fields began to investigate fully the 
foundations on which their field was based. 

To date, although there have been many, many 
software problems, there have been no major disasters 
that have been directly attributed to software. How- 
ever, unless a sound epistemological foundation is 
established for software engineering, disasters will 


come one day. To avoid this, research is needed to 
develop valid approaches to answering questions about 
both software products (e.g., are these requirements 
consistent?) and software processes (e.g., is method A 
better than method B?). 

The Assessment Technology Branch (ATB), 
which is part of the Information and Electromagnetic 
Technology Division, Research and Technology Group, 
is currently investigating empirical methods to answer 
process-type questions and logical methods to answer 


product-type questions. The remainder of the presenta- 
tion discusses the second of these two avenues of 
research. 
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A team led by Ricky W. Butler has been studying 
the discipline of formal methods for over 6 years. 

Other civil-servants on the team are Jim L. Caldwell, 
Victor A. Carrefto, C. Michael Holloway, and Paul S. 
Miner. Vigyan, Inc., Stanford Research Institute Inter- 
national (SRI), Odyssey Research Associates (ORA), 
and Computational Logic, Incorporated (CLI) conduct 
research under contract. 

Formal methods is 1 the applied mathematics of 
computer systems engineering 2 . Formal methods aims 
to be to software engineering what fluid dynamics is to 
aeronautical engineering and what classical mechanics 
is to civil engineering. The mathematics of formal 
methods includes predicate calculus (first order logic), 
recursive function theory, lambda calculus, program- 
ming language semantics, and discrete mathematics 
(e.g., number theory, abstract algebra). To this mathe- 
matical base, formal methods adds notions from pro- 
gramming languages such as data types, module 
structure, and generics. 

There are many different types of formal methods 
with various degrees of rigor. The following is a useful 
classification of the possible degrees of rigor in the 
application of formal methods: 

• Level 0: No use of formal methods 

• Level 1: Formal specification (using mathematical 
logic or a specification language with formal seman- 
tics) of all or part of a system 

• Level 2: Formal specification at two or more levels 
of abstraction and paper- and-pencil proofs that the 
detailed specification satisfies the abstract one 

• Level 3: Like level 2, except paper- and-pencil 
proofs are replaced by formal proofs checked by a 
semi-automatic theorem proven 

Presently, a complete (level 3) verification of a large, 
complex system is impractical; however, application of 
formal methods to critical portions of a system is prac- 
tical and useful. 

The specification of a simple phone book provides 
a suitable simple example of many of the basic ideas 
and benefits of formal methods. Please see the presen- 
tation visuals that follow this abstract for this example. 

Because of the promise that formal methods offers, 
a considerable amount of high-quality research is being 
conducted or sponsored by ATB. This research 
includes, but is not limited to, the following projects: 


1 . Just like mathematics, formal methods should be treated as a 
singular, not plural, noun. 

2. The ideas apply equally well to both software and complex 
hardware devices. 


• Detailed design with complete level 3 verification of 
the Reliable Computing Platform, which is a fault- 
tolerant computing base able to recover from both 
permanent and transient faults 

• Design with level 2/3 verification of a transient fault- 
tolerant clock synchronization circuit; this circuit has 
also been fabricated, but the layout was done by 
hand without formal verification 

• In cooperation with SRI and Rockwell-Collins, level 
3 specification and verification of the microcode of 
the AAMP5 microprocessor 

• In cooperation with ORA and Union Switch and Sig- 
nal, level 3 specification and verification of a next- 
generation railroad control system 

• Under contract, ORA is working with Honeywell on 
level 3 specification and verification of aircraft navi- 
gation functions 

• Under contract, Vigyan and SRI are working with 
Loral, Johnson Space Center, and the Jet Propulsion 
Laboratory on level 3 specification and verification 
of some Space Shuttle functions 

• Under contract, SRI is working with Allied-Signal 
On level 3 specification and verification of important 
algorithms for fault-tolerance 

In addition to these, and other, projects, the branch 
conducts periodic workshops on formal methods. Pre- 
vious ones were held in 1990 and 1992; the next one is 
planned for 1995. Also, an extensive collection of 
information on the research is available through the 
World Wide Web at the following Universal Resource 
Locator: 

http://shemesh.larc.nasa.gov/fm-top.html 

Interested individuals are encouraged to explore this 
collection. 

A lot of ground has been covered in this presenta- 
tion, but the most important point is simple: 

Epistemology: It’s important, learn about it 
Software Engineering: It’s immature, work on it 
Formal Methods: It’s promising, look for it 
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Epistemology 
Software Engineering 

and 

Formal Methods 


C. Michael Holloway 

Assessment Technology Branch 
Information & Electromagnetic Technology Division 
Research & Technology Group 
Langley Research Center 
National Aeronautics and Space Administration 
United States Government 


Th* Rote e* Computer* In LaRC RIO (June 10-1 6, 1 9*4) 


introduction 


. One of the most basic questions anyone can ask is 
“How do I know that what I think I know is true?” 


• The study of this question is called epistemology 

• Traditionally, epistemology has been considered to be of 
legitimate interest only to philosophers, theologians, and 
three-year-old children 

• At least one other group should be very interested in 
epistemology - software engineers - because lack of 
understanding in this area plagues the field 
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The Basics of Epistemology 


* There are three basic answers to the question of how do we 

know what is true 

— Authority: truth is given to us by a knowledgeable person 

-- Reason: truth is what can be proven using the rules of 
deductive logic 

-- Experience: truth is what can be encountered through 
one or more of the senses 

* Anecdotal experience: truth is what an individual or a 
group of individuals experiences personally 

* Empirical evidence: truth is what can be verified 
through carefully controlled experiments 


Exsmplos of Truth by Authority 


• The Ten Commandments 

(omniscient authority) 

■ 1 -year-old, pointing to the family cat: 
“Whatsthat?” 

father: “Kitty” 

(human authority) 
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Examples of Truth by Reason 


• If that creature is a tove, then it is slithy 
That creature is a tove 

Therefore, that creature is slithy 

• If the airplane was built by Boeing, then it is a jet 
The airplane is not a jet 

Therefore, the airplane was not built by Boeing 

. X + Y = 7 
3Y - 2X = 1 

Therefore, X = 4 and Y = 3 


Examples of Truth by Anecdotal 
Experience 

Smoking doesn’t shorten your life because my 
father smoked all his life and lived to be 95. 

Whenever I have the hiccups, I hold my breath 
and count to 1 0 and they go away. Therefore, 
holding your breath and counting to 1 0 cures 
the hiccups. 

We used method M and had 40% fewer bugs in 
testing. You should use method M, too. 
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Examples of Truth by Em pin cel 

Evidence 

. The dive-recovery flap for the P38 in World War 
II developed through tests in Langley’s 8-Foot 
High Speed Tunnel 

• 5,000 patients were given drug X. 5,000 
patients were given no drugs at all. 4,998 of 
the patients given drug X got better within 1 
week. 3 of the patients given no drugs at all got 
better within 1 week. Drug X helps. 


Relative Strengths 


. Omniscient Authority: absolute truth 

■ Reason: conditional absolute truth 

• Empirical Evidence: probable truth 

• Anecdotal Experience: possible truth 

• Human Authority: opinion 
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How Does This Apply to 
Software Engineering? 

. The software engineering community is full of claims 

‘The best way to develop reusable software is to use object-oriented design." 

“Programmers should never be allowed to test their own code. " 

“Getting control of the software process is the key - SEI’s CMM is the way to do 
this." 

“We need more standards /" 

“Much progress has been made in the last few years in improving the way we 
develop software." 

“GOTO’s are harmful." 

“CASE tools are the best way to improve software productivity 

• Many people accept these, or other similar, claims as being 
true 


The Fundamental Ouestion 


What is the 

epistemological foundation 
for accepting 
these claims? 
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The Answer 

• Logically sound arguments are rarely given 

• Virtually no empirical evidence is cited 

• Instead, software engineering is based almost entirely on a 
combination of human authority and anecdotal experience 

-- We know that technique C is good because Jane Doe, 
who is a recognized authority in the field, says that it is 
good (human authority) 

— Jane Doe knows that it is good because she used it on a 
project once and got good results (anecdotal experience) 

• This is a weak epistemological foundation, one on which no 
legitimate claims of success can be based 


Implications of 

Weakness 


* Until we get adequate evidence, we should be very 
cautious in the claims we make and the standards we set 

- - It is fine to say, “i Method M seems to have improved our productivity, so you 

might want to try it." 

But it is dishonest to say , “if you want to improve your productivity, you must 
use Method M" 

- - “Company R used method F and found errors they don’t think they would 

have found using their old methods,” \$ fine 

“Method F finds errors that other methods do not find” is dishonest 


• The software engineering community should be 
investigating methods for obtaining strong (that is, logical or 
empirical) evidence 
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Why Has More Not Been Done? 


• The development of software engineering is following the 
same pattern as the development of other disciplines 

-- Civil engineering, chemical engineering, aeronautical engineering, etc. all 
had periods in which they relied almost exclusively on anecdotal evidence 

- - Often, it took major disasters to prompt changes 

• It is hard 

• It is expensive 

• It is not glamorous 

• Few people care: We haven’t had a major disaster yet 


Why Must More Be Done? 


. Without adequate evidence, we are easily influenced by the 
latest bandwagon that goes rumbling by 

. Without adequate evidence, we may well “cast-in-concrete” 
something that ought not even be “cast-in-mud” 

• Without adequate evidence, the following two statements 
are equally as meaningless: 

— you shall use method M in developing your software 

- ‘Twas brillig by the slithy tove 

. Without adequate evidence, disasters are inevitable 
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Towards Establishing a Valid 
Epistemological Foundation 


• Recognize the fundamental need for such a foundation 

• Understand the different approaches needed for process 
and product 

-- Process questions (e.g., Is method A better than method 
B7) need to be answered empirically 

~ Product questions (e.g., Are my requirements 
consistent?) need to be answered by an appropriate 
combination of logical and empirical methods 

• Refuse to accept claims based on insufficient evidence 


Current Reseerch 8t LaRC 

• Kelly Hayhurst (IETD/ATB) is leading an effort to develop 
an empirical evaluation of a particular approach to IV & V 

For more information, contact Kelly 
Email: k.j.hayhurst@LaRC.NASA.GOV 
Phone: 46215 

• The formal methods team led by Ricky Butler (IETD/ATB) is 
investigating logical methods for answering product-type 
questions 

-- Other team members are Jim Caldwell, Victor Carreho, 
Michael Holloway, and Paul Miner 

— Remainder of talk concerns this work 
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Further Raading on Epistemoiooy 


If you are interested in more information on epistemology, I 
recommend you start with the following two books: 

- Thales to Dewey, by Gordon H. Clark, 2nd edition, 1989, 
ISBN 0-94093 1-26-5 

- The Philosophy of Science, by Gordon H. Clark, 2nd 
edition, 1987, ISBN 0-940931-18-4 

These two books contain pointers to most of the important 
philosophical works throughout the ages 


Singular or Plural? 

Which of the following is correct? 

Formal methods is the applied mathematics ... 
OR 

Formal methods are the applied mathematics ... 
Answer depends on the writer or speaker 
I will tend to use “formal methods” as singular 
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What is Formal Methods? 


• Formal methods is the applied mathematics of computer 
systems engineering 

• The mathematics of formal methods includes: 

-- predicate calculus (1st order logic) 

~ recursive function theory 

-- lambda calculus 

-- programming language semantics 

-- discrete mathematics : number theory, abstract algebra, 
etc. 


What is Formal Methods? 

(continued) 


System Designed 

Engineering 

Theory 


Civil 

Classical Mechanics 


Aeronautical 





Digital Avionics 
System 

Software 
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Classical vs Computer Systems 


Classical Systems 

Computer Systems 

continuous state space 

discrete state space 

smooth transitions 

abrupt transitions 

finite testing & interpolation 
acceptable 

finite testing inadequate, 
interpolation unsound 


prototyping & testing 

build to withstand additional] 
stress 1 

build to specific 
assumptions 


surprising 


What Makes a Technique a 
Formal Method? 

• Formal method = logic + programming language concepts 

. Important attributes: 

-- logic based 

- programming language concepts (e.g., data types, 
module structure, generics) 

- fully and formally specified semantics 

-- should be able to express what is done without saying 
how it is done (i.e., non-procedural) 

- supports the building of useful tools for analysis 


582 





















Levels of Rigor of Formal Methods 

• Level 0: No use of formal methods 

• Level 1: Formal specification (using mathematical logic or 
a specification language with formal semantics) of all or 
part of a system 

• Level 2: Formal specification at two or more levels of 
abstraction and paper-and-pencil proofs that the detailed 
specification satisfies the abstract one 


• Level 3: Like level 2, except paper-and-pencil proofs are 
replaced by formal proofs checked by a semi-automatic 
theorem prover 


Extent of Appficetion 

♦ Formal Methods is not an all-or-nothing approach 

• Complete formal verification of a large complex system is 
impractical at this time 



• Application of formal methods to critical portions of a 
system is practical and useful 
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Extent of Application (example) 


• In the Reliable Computing Platform, we use formal methods 
to establish: 

ENOUGH_WORKING_HARDWARE 

o 

PROPER_OPERATION 


• We use reliability analysis to calculate: 

Probability[ENOUGH_WORKING_HARDWARE] 

■ Reliability analysis relies on physical testing of devices to 
establish some important parameters 


Level 1 Example: Phone Book 

English Requirements 


• The phone book shell store the phone numbers 
of a city 


• Given a name, there shall be a way to retrieve 
an associated phone number 

• It shall be possible to add and delete entries 
from the phone book 
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Level 1 Example: Rhone Book 
Choosing a Specification Approach 

• How do we represent the phone book mathematically? 

1 . A set of ordered pairs (name, number). Adding and 
deleting entries is by set addition and deletion. 

2. A function whose domain is all possible names and 
range is all phone numbers. Adding and deleting entries 
is by modification of function values. 

3. A function whose domain is only names currently in the 
phone book and range is phone numbers. Adding and 
deleting entries is by modification of the function domain 
and values. (Z style) 

• We choose to use approach 2 


Level 1 Example: Phone Book 
Specifying the Book 

• Using traditional mathematical notation, we would write: 

Let n = set of names 

p = set of phone numbers 

book: N —> P 

• To indicate that we do not have a phone number for all 
possible names, but only for names of real people, we 
decide to use a special number: pep 

• An empty phone book is specified as follows: 

emptybook: N -» P 
emptybook (nm) = p 
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Level 1 Example: Phone ElooK 
Accessing an Entry 

Let n = set of names 

p = set of phone numbers 
book: N —> P 
b - set of functions: n p 

FindPhone: B X N — > P 

FindPhone (bk, name ) = bk( name) 

Note that FindPhone is a higher-order function, because its 
first argument is a function 


Level 1 Example: Phone 
Adding/Deleting an Entry 


Let n = set of names 

p = set of phone numbers 

book: N — > P 
p G P 

b = set of functions: n p 


AddPhone: B X N X P — » B 
AddPhone ( bk , name f num ) (x) = 


bk(x) if x^name 
num if x = name 


DelPhone: B X N B 
DelPhone (bk, name ) (x) - 


bk(x) if x&name 
p if x = name 
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Level 1 Example: Phone Book 
Complete Specification 

Let n = set of names 

p = set of phone numbers 

book: N P 

pep 

b = set of functions: n -> p 

emptybook: i\T — > p 
emptybook ( um ) s p 

FindPhone: B X N P 
FindPhone ( bk, name ) = bk(name) 

AddPhone: B X N X P B fbk(x) if x*name 
AddPhone (bk, name, num ) (x}={ 

[num if x = name 

DelPhone: B x N -> B ( bk(x ) if x^name 
DelPhone(bk,name) (x)={ 

Ip if x = name 


Level 2 Example: Phone Book 
Putative Theorems 

A putative theorem is a theorem that we know must be true if 
we have formulated the specification correctly. 

Lemma putative 1 : 

FindPhone (AddPhone (bk, name, num ), name) = num 

Proof: 

FindPhone ( AddPhone ( bk, name, num ) , name ) = num 
AddPhone (bk, name, num) (name) = num 
num = num 

Q.E.D. 
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Level 2 Example; Phone Book 

Putative Theorems (continued) 

Lemma putative 2: bk(name) ~ p 3 
DelPhone ( AddPhone (bk, name r num) , name) - bk 

Lemma putative 3: (Vi:name± & name) a 

book = AddPhone (bk, name , num) a 
booJq = AddPhone (book, name [ , ; a 

book} * AddPhone ( book, , name, , num, ) a 

b°°K = AddPhone ( book L , name n , num D ) 

FindPhone(booJg , name) = num 

Formal methods can establish that a property holds even in 
the presence of an arbitrary number of operations; testing 
can never establish this. 


Level 3 Example: Phone 
PVS Specification 



Phonebook : THEORY 
BEGIN 

names : TYPE 
nameO : names 
ph_number : TYPE 
p_0 : ph_number 

book: TYPE “ [names -> ph_number] 
name : VAR names 

emptybook ( name ) : ph_number * p_0 
bk: VAR book 

FindPhone(bk, name): ph_number - bk(name) 
num : VAR ph_number 

AddPhone (bk, name, num): book - bk WITH [name :« num] 

DelPhone (bk, name): book - bk WITH [name :- p_0] 

putative_l : LEMMA FindPhone (AddPhone (bk, name, num) , name) *• num 

putative_2: LEMMA bk(name) - p_0 IMPLIES 

Del Phone ( AddPhone (bk, name, num), name) - bk 


END Phonebook 
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Formal Methods 
It’s Promising, Look For It 
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Level 3 Example: Phone Book 



putative_l s 

I 

{1} (FORALL (bks book), (nm: names), (nums ph_number): 

FindPhone( AddPhone(bk, nm, num), nm) = num) 


Rule? (skosimp*) 

Repeatedly Skolemizing and flattening, 
this simplifies to: 
putative_l : 


[1) FindPhone ( AddPhone ( bk 1 1 , nmll, numil), nmll) = numll 


Rule? (expand "FindPhone" ) 


Level 3 Example: Phone Book 
Proof Using PVS (continued) 

Rule? ( expand "FindPhone" ) 

Expanding the definition of FindPhone, this simplifies to: 
putative__l : 


{1} AddPhone (bkl 1, nmll, numll) (nmll) - numll 
Rule? (expand "AddPhone" ) 

Expanding the definition of AddPhone, this simplifies to: 
putative_l : 


{ 1 } TRUE 

which is trivially true. 
Q.E.D. 

Run time « 1.02 secs. 
Real time - 20.00 secs. 
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Level 1 Example: Phone Book 

Deficiencies in the Specification 


• Our specification does not rule out the possibility of 
someone having a “p” phone number 

. We have not allowed multiple phone numbers per sinale 
name 

• Our specification does not say anything about whether 
there should be a warning if a deletion is requested on 
name that is not in the phone book 


How do we remedy these deficiencies? 


Level 1 Example: 

Overcoming Deficiencies 1 & 2 


Let n - set of names 

p = set of phone numbers 

book: N 2 P 
B = set of functions: n 2 P 


emptybook(name) = 0 

FindPhone: B X N -» 2 P 
FindPhone ( bk, name ) = bk ( name ) 

AddPhone: B x N x P B f bk(x ) if x*name 
AddPhone ( bk, name, num ) (x)-^ 

IJbJr ( name )kj{ num } 
if x = name 

DelPhone: B x N — > B ( bk(x ) if x^name 
DelPhone ( bk, name ) (x)={ 

0 if x = name 
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Level 1 Example: Phone Book 
An Additional Deficiency 

• Notice that the function DelPhone deletes all of the phone 
numbers associated with a name 


• There is no way to remove just one of the phone numbers 
that is associated with a given name 


• The original requirements did not address this situation; to 
address it, we must define an additional function: 


Del Phon eNum : B X N X P — * B 


DelPhoneNum(bk, name, num ) (x) = 


bk (x) if x name 

bk f name) \{num } 
if x = name 


Example: Phone Book 
Revised Requirements 

Original Requirements 

• The phone book shall store the phone numbers of a city 

• Given a name, there shall be a way to retrieve an associated phone number 

• It shall be possible to add and delete entries from the phone book 

Revised Requirements 

• For each name in the city, a set of phone numbers shall be stored 

• Given a name, there shall be a way to retrieve the associated phone numbers 

• It shall be possible to add a new name and phone number 

• It shall be possible to add new phone numbers to an existing name 

• It shall be possible to delete a name from the phone book 

• It shall be possible to delete one of the phone numbers associated with a name 

• A warning need not be given for a requested deletion of a name not in the city 

. A warning need not be given for a requested deletion of a non-existent Dhone 
number H 
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Example: Phone Book 

Observations 

• Our specification is abstract. The functions are defined 
over infinite domains. 

• In translating the requirements from English into a more 
formal notation, many things that were left out of the 
English were explicitly enumerated. 

• The formal process exposed ambiguities and deficiencies 
in the requirements. E.g., we had to choose between 

book: N — » P 
book: N — > 2 P 

• Putative theorem proving and scrutiny revealed deficiencies 
in the formal specification 


Example: Phone Book 
More Observations 


• There are many different ways to formally specify 

• No matter what representation you chose you are making 
some decisions that bias the implementation 

• The goal is to minimize this bias and yet be complete 

• The process of formalizing the requirements can reveal 
problems and deficiencies and lead to a better English 
requirements document also 

• The formal specification process is similar to the 
mathematical modeling process of engineering disciplines 
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Formal Mathods Rasaarch at LaRC 

• Detailed design with complete level 3 verification of a 
Reliable Computing Platform 

• Design with level 2/3 verification of a transient fault-tolerant 

clock synchronization circuit ao! ^ the circuit 

• With SRI Internationa! & Rockwell-Coflins, level 3 
specification and verification of the microcode of the 
AAMP5 microprocessor 

• With Odyssey Research Associates & Union Switch and 
Signal, level 3 specification and verification of next- 
generation railroad control system 

• ORA & Honeywell, level 3 specification and verification of 
aircraft navigation functions 


Formal Methods Research at LaRC 

(continued) 

• Vigyan & SRI working with Loral, JSC, JPL on level 3 
specification and verification of some Space Shuttle 
functions 

• SRI working with Allied-Signal on level 3 specification and 
verification of important algorithms for fault-tolerance 

• Conduct periodic workshops on formal methods; previous 
ones in 1990, 1992, with next one planned for 1995 

• Maintain extensive collection of information on the 
research, accessible through the World Wide Web at URL 

http://shemesh.iarc.nasa.gov/fm-top.html 
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